Computer network traffic is normally sent unsecured without encryption or strong authentication by a sender and a receiver. This allows the traffic to be intercepted, inspected, modified or redirected. Either the sender or the receiver can falsify their identity. In order to allow private traffic to be sent in a secure manner, a number of security schemes have been proposed and are in use. Some are application dependent, as with a specific program performing password authentication. Others such as (TLS) are designed to provide comprehensive security to whole classes of traffic such as Hypertext Transfer Protocol (HTTP) (i.e., web pages) and File Transfer Protocol (FTP), i.e., files.
Internet Security (IPsec) was developed to address a broader security need. (See Demystifving the IPsec Puzzle, Frankel, S., Artech House (2001)) As the majority of network traffic today is over Internet Protocol (IP), IPsec was designed to provide encryption and authentication services to this type of traffic regardless of the application or the transport protocol. This is done in IPsec tunnel mode by encrypting a data packet (if encryption is required), performing a secure hash (authentication) on the packet, then wrapping the resulting packet in a new IP packet indicating it has been secured using IPsec.
Normally, the shared keys used by IPSec are established one of the two ways: manually or using the Internet Key Exchange (IKE) protocol. In load-balanced or highly redundant networks where traffic can be sent and/or received through multiple paths, there are no single pairs of Policy Enforcement Points (PEP) that can perform negotiation or be selected as the source or destination in the tunnel head as required by IKE. As such, in highly complex mesh networks, for example, where there are a number of networks and endpoints, the number of the policy required on each PEP becomes extremely large and management become more difficult with increasing scale as the number of networks increase.
Therefore, some networks implemented data protection managing technologies to resolve these problems while maintaining the existing IKE/IPSec gateway functionality. An example of this is disclosed in U.S. Provisional Application No. 60/813,766 filed on Jun. 14, 2006, the entire teachings of which are hereby incorporated by reference. Such a data protection managing technology separates policy management, key generation and distribution from policy enforcement and handles extremely large number of network. This works either for multiple paths in a redundant network or for many networks in a multicast scenario. In addition, the data protection managing technology greatly simplifies policy generation by grouping networks and Policy Enforcement Points (PEPs).
Despite the advantages of data protection, and improved management of key generation and distribution, there are a number of situations where a user may need to interface with a standard IKE device for use in the secure network. In addition to supporting legacy devices, this may be needed to detect Network Address Translation (NAT) between a remote client and a gateway of the secure network. Also, it could be useful in applying IKE for authentication.
Standard IKE, however, is insufficient for distributing keys to multiple PEPs units. IKE works only with point to point connections, with keys installed on each endpoint. Furthermore, standard key distribution using data protection managers does not suffice because it does not provide an interface to standard IKE systems and cannot detect NAT devices.
Therefore, there is a need for a network security technique for creating a secure tunnel between a local network equipped with data protection managing technologies and a remote standard device so that encrypted packets can be exchanged without comprising network security.